Management 3.0 - Develop competence

Chapter 10 : The Craft of Rulemaking

人は 「X の状況が発生した場合に Y を実行しなければならない」 というルールを作り、将来の問題に対処することがある

これは良くない : マネジャーによるルール作成は組織の安定性への最善のアプローチではない

この章は能力開発 (Develop Competence) について

複雑適応系における学習能力の一般的なパターン

これらのルールを適用した結果、フォローアップルールまたは外部環境のいずれかに多数の新しいメッセージが送信される

例 : ソフトウェア開発者である筆者の心は、ソフトウェアを構築するためのたくさんのルールで満たされている

環境から受け取る入力 : 同僚が行っていること、自分が取り組んでいるコード、顧客からの要件、機能と制限など

評価 : 意識的および無意識の両方で、数千とは言わないまでも数百のルールを使用して並行して評価される

結果 : 記述されるコード、既存のコードの変更、会話など、1 つ以上の新しいアクション

パフォーマンスシステムはルールの生態系であり、ルールが互いに競合し、協調しているように見える

「最も適切な」 ルールは、複雑な適応システム全体に最も効果的に貢献するルール

システム全体のパフォーマンスの向上につながると思われるルールは信用されて、パフォーマンスシステム内での強度が向上

トリガーされ、その後有益な効果を提供できなかった、またはシステム全体を傷つけたように見えるルールは、その強度が低下

各ルールの強度によって、同様の入力メッセージに対して次回トリガーされる可能性が決まる

貢献度分配により、一部のルールを強化し、他のルールを弱めることで、システムに経験を積み上げる

環境が変化すると、またそれに応じた貢献度分配がなされるので、パフォーマンスシステムは新しい状況に適応

どこから新しいルールを学ぶか？ → Holland は、積み木を再結合することにより、既存のルールから新しいルールを構築する方法について説明

これは本質的にDNAがどのように機能するか : 既存の遺伝子とそれらの対立遺伝子の組換えによる。

Holland は、複雑適応系でルールベースの意思決定を行うための進化モデルを最初に作成した企業の 1 つ

鳥の群れを簡単にモデル化できる

3 つの制約 : 同じ方向に飛ぶ、お互いにぶつからない、グループから離れない

人のチームも似ている

群れの複雑な振る舞いが、少数のルールから実現されることがわかる

複雑系の各エージェントの刺激応答により、全体の複雑な振る舞いが実現

ただし、ここでいう 3 つの制約は、実際の各エージェントの刺激応答のルールではない

各エージェントは、3 つの制約を満たすように、より細かな刺激応答ルールを自身の中に持っている

例 : 見える範囲の鳥との距離を計算する、距離が一定より近い場合には離れる、など

刺激応答ルールをマネジャーが決めるのは正しくなく、マネジャーは制約を定めるだけにすべき

複雑適応系の力は、エージェントが独自のルール作成プロセスを管理できること

アジャイルソフトウェア開発は、ソフトウェアプロジェクトを管理し、創造的な人々と協力するための自然なアプローチ

「顧客とのコラボレーション」、「頻繁な変更の許可」、「機能するもののみを提供する」 などの制約は設定される

「吹雪で旅行が困難になった場合は、Skypeを使用して毎週デモを行います」、「変更リクエストがある場合は、ソースに新しいブランチを作成します」 などのルールを選択して実装するのはチームの責任

アジャイルソフトウェア開発は、ペアプログラミング、TDD、またはユーザーストーリーについて必須にはしていない (アジャイルマニフェストはこれらのいずれにも言及していない)

よく知られた慣行は、貴重な知識と経験の源として重要ではある

が、それらを固定ルールとして課すほど、チームメンバーの固有のルール作成機能が制約される

そうすると、彼らは本当にアジャイルになる能力を失ってしまうだろう

アジャイルの盲点

アジャイルマニフェストは、明示的には 「ソフトウェアプロジェクトに優秀な人の存在が必要である」 ことを示していない

アジャイルは、チームが優れている場合にのみ優れている (もちろんアジャイル以外でも優れたチームが重要ではある)

この問題を扱うため、アジャイルマネジメントと交通マネジメントを比較

オランダの交通安全の実現には、下記の 7 つ以上の補完的なアプローチがあり、背後にある考え方はソフトウェアプロジェクトでも有効

文化 : 他の人を気にする文化

社会システムの能力を達成するために他にどんな方法を適用しても、結局それはすべて人々が気にかけるかどうかに依存する

インストラクター : オランダでは、インストラクターの助けを借りてのみ運転を学ぶことができる

人々に彼らの仕事を正しく行う方法を教える必要がある。 何度も何度も何度も

運転免許証 : テストを受けて、交通に参加できることを証明する必要がある

人々が (挑戦的な) プロジェクトに参加することを許可する前に、人々が適切にテストされることを要求する

交通標識 : オランダは世界で最も交通標識が多い国だと思う (by 筆者)

スマートでプロアクティブなツール、チェックリスト、アラート、通知、その他の規制関連のものを使用して、チームで問題が発生する可能性を減らす

交通警察

プロジェクトの結果のサンプルを取り、高品質の出力が生成されるかどうかを確認することを仕事とするプロセスマネジャーを歩き回らせる

車のクラクション : これは筆者の車のお気に入りの部分

死傷者の数を最小限に抑えるには、自分または他の誰かを危険にさらしていることを他の人に知らせることが重要

チームメンバーが日常業務を改善する方法をお互いに伝える勇気を持っていることを確認しする

(比ゆ的に言えば、彼らに警笛を鳴らさせましょう)

ガバメント : 他のすべてが失敗したとき、政府は介入します。彼らは何が悪かったのかを調査します。 彼らは新しいルールや制約を作ります。 そして彼らは誰が正しいか誰が間違っているかを決定します。

経営陣 (マネジメント) は混乱を一掃する必要があります。

賢く、規律があり、気配りのある人にとっては運転免許証も交通標識も必要なければ、警察によって道路から連れ去られることもない

この状況はほとんどのアジャイル開発手法が想定していることだが、それは死角である

世界は、そして、ほとんどのドライバーも従業員も完璧ではない

マネジメントは死角に対処する方法と安全に運転する方法を理解する必要がある

技能の重要性

その結果、多くの人がアジャイルを 「規律のない」 と誤って解釈したり、ソフトウェアチームの熟練した規律のある資質に取り組む必要があることを忘れたりするという問題が発生

真実は、規律はソフトウェア開発 (および他の多くの職業) に不可欠

残念ながら、多くの人が自分は良いドライバーだと思っているが、積極的に良いドライバーになることを学ぶ人は多くない

アジリストは職人技を前提としている

職人技を追求する人はほとんどいない

職人技は、アジャイル自体では導入されないもの

そして、それについて考えて話すだけでは、プロジェクトを成功させることはできない

より良い結果を望むマネジャーは、人々の態度や行動を積極的に変えなければならない

ポジティブフィードバック

良い影響が出ることも悪い影響がでることもある。 悪循環にもなりえる

正のフィードバックループは、自己組織化に重要

ポジティブフィードバックループを認識する方法を知ることは、組織が特定の種類の行動にとらわれる理由を理解し、それに対して何かをすることができるため、重要

ネガティブフィードバックループを認識することも同様に重要

これにより、システムの変更が非常に難しい場合がある理由を理解できる

ネガティブフィードバック

チームメンバーがグループの規範に違反した場合、メンバーは是正措置について相談し、合意することができる

暴走したプロジェクトでは、テクニカルレビューは物事を制御下に戻すのに役立つ反対のフィードバックループを導入できる

The classic example is the household thermostat, which senses room temperatures and turns the furnace on or off accordingly. To use the system scientist William T. Power’s classic formulation, feedback “signals” are compared to the internal “reference signals,” and it is the relationship between the two signals that determines what the behavior of the system will be. Any usage of the term “feedback” that departs from this goal-oriented, information-driven model is at best metaphorical and at worst misleading.

サイクルは長いよりも短い方が優れていることが多い

負のフィードバック自体もネガティブフィードバックの影響を受ける

短い方が良いが、短くしすぎると効果が悪くなるところがある

システムには多くの参加者が居て、正と負のフィードバックループが多数あるため、複雑

規律 × 技能 = 力量 (コンピテンス)

規律

どんな仕事でも規律の重要性は明らか

私たちは皆、個人的な経験から、最終的には、規律をスキップすると、速くなるのではなく、遅くなることを知っている

チェックリストと手順をスキップすると、最初は速くなる

Weinberg による、プロセスの 6 つの成熟度レベル (six maturity level)

忘却 : プロセスを実行していることすら知らない

変数 : 私たちは現時点で好きなことを何でもする

ルーチン : 私たちはルーチンに従う (パニックの場合を除く)

ステアリング : 私たちはルーチンの中から、それらが生み出す結果に基づいて選択する

予測 : 私たちは、過去の経験に基づいてルーチンを確立する

合同 : 誰もが常にすべてを改善することに関与している

Weinberg はこのレベルを組織に適用して分類したが、筆者としては個人への適用を好む

組織で起こることは、個人間の相互作用の結果であるため

Regressive, Neutral, Collaborative, Operating, Adaptive, and Innovating

技能

規律と同様、技能もランク付けできる

3 段階のモデル

最初のレベルにランク付けされた人々は基本的なテクニックを学ぶ

第 2 レベルにランク付けされた人々は、例外と反省に焦点を合わせる

第 3 レベルの人々にとっては、難しい考えは必要なく、すべてが自然に起こる

5 つの段階 (初心者、上級初心者、有能、熟練、専門家) で構成される

スキルは規律とは異なるため、個別に開発する必要がある

規律とスキルの2つの次元を描くと、規律-技能グリッドになる

成熟度を 2 つの方向で測定できることをうまく表している

コンピテンシーには両方が必要であるため、マネージャーは両方の側面に注意を払う必要がある

チームメンバーはルールに従うが、チームのルールもあれば個人のルールもある

見積り時にストーリーポイントと理想日が混ざっているとやりづらい

会議の予定や長さも合意する必要がある

一方で、コード上の取り決めはそこまで強くなくても良いかもしれない

マネジャーは、チーム内のルールの無意味な同期に注意する必要がある

人々は自分のやり方で物事を行うことを許可されるべき

この自由はやる気を維持するのに有用

他のメンバーの出力が自分のルールよりも優れていることが判明したときに、互いのルールをコピーすることを選択できる

チーム内の競合するルールは全体を強化する

すべてのチームメンバーが同じルールを使用して同じ方法でコードを処理すると、ソースコードの問題が検出されない可能性がある

第 4 章で見たように、多様性がチームの柔軟性と回復力を高める

どのルールに誰が従うべきかどう決めるか？

問題は、最小、最低位、または最低限の中央集権化された管轄当局によって処理されるべき、という組織化の原則

オックスフォード英語辞典では、補完性を、中央当局が補助的な機能を持ち、より直接的なレベルまたはローカルレベルでは効果的に実行できないタスクのみを実行するという考えとして定義

この概念は、政府、政治学、サイバネティックス、および管理の分野に適用可能

ルールは、タスクを効果的に実行できない場合を除いて、個々の責任

タスクを効果的に実行できない場合は、ルールは階層の 1 つ上のレベルで確立する必要がある

例 :

チームレベルで集中ルールを確立することがより効果的であるとチームが証明できない限り、単体テストの作成には独自のルールを用いることができる

同時に、スプリント計画会議を個人レベルで効果的に行うことができないことは明らかなので、自動的にチームの責任になる

人々は自分でルールを作ることができ、そのためのマネージャーは必要ない

信号機や標識を取り除くと、交通の流れが増えると同時に、死傷者が減る

矛盾しているようなこの事象の理由は、リスク認識と誤ったセキュリティにある

信号機 (誤ったセキュリティ) を取り外すことにより、運転手は自分が優先されると思わないし、横断歩道がなくなることで歩行者は注意するようになる (リスク認識)

交通のすべての参加者が平等で、全員がお互いに注意しなければならないことを意味する

誰も他の人よりも優先されるべきではない

コードの開発方法などのルールは、自動的に高品質に繋がるとは限らない

プロジェクト特性を考慮に入れないルールは、むしろ誤ったセキュリティですらある

ほとんどのプロジェクトでは、既存のルールを法律としてではなく、経験則として扱う必要がある

人々が盲目的に規則に従うのを防ぐために、規則を廃止する必要がある場合がある

プロジェクトで不快な事件が発生し、将来同様の問題を防ぐために新しいルールが必要であると誰かが呼びかけているとき、筆者は通常控えめになる

何かうまくいかないことが起こったとき、それが起こらないように法律を作る

いくつかの方法論とフレームワークは、予防原則に基づいているように見える

それらは、あらゆる種類の潜在的な問題についてプロセスの説明を追加することを提案している

残念なことに、物事をより良く実行するためにいくつかのプロセスを削除する必要があるかもしれないと示唆しているものはない

幸いなことに、ソフトウェア開発の分野では、単一の方法論が適切ではないことを言っている人が居る

例 : サンタクロースはミームで、クリスマスツリーもミームで、プレゼントを靴下に入れるのもミーム

ソフトウェア開発のルール、手順、慣行についても同じ

人々が模倣、相互作用、および学習を通じて互いにコピーする

スタンドアップミーティングやペアプログラミング、リファクタリング、反復型開発はミーム

ミーム学は、文化的な文脈での情報伝達の進化モデルの研究

クリスマスは典型的なミームプレックス。 アジャイルソフトウェア開発もそう

アジャイルソフトウェア開発の実践も同様で、お互いを強化する傾向がある

アジャイルプラクティスのほとんどは、アジャイルソフトウェア開発のずっと前からすでに存在していた

しかし、それは重要なことではなく、重要なことは、アジャイルミームプレックスの台頭が、多くのアジャイルプラクティスのコピー狂乱を、彼ら自身では決して到達できなかったレベルにまで触媒した

アジャイルミームプレックスが強力なことは筆者も実感した

アジャイルの個々のプラクティスを個別に導入しようとしてもうまくいかなかった

スクラムもまたミームプレックス

アジャイルプラクティスをミームとして見た時に得られる興味深い洞察

1つだけを採用するよりも、複数のアイデア、概念、または実践を同時に採用させる方が簡単な場合がある

例 : 単体テストだけでなくエクストリームプログラミングを適用するように指導し、すぐに組織のコンテキストに XP を適応させ始める

ミームプレックスでは、すべてのアイデア、概念、および実践が有益である必要はない

いくつかは有害である可能性もあるが、それらはすべて同じミームプレックスの一部であるため、悪いアイデアは良いアイデアをコピーするのにも役立ち、悪い影響を中和する

例 : 集合的なコード所有権の価値の決定的な証拠を見たことはないが、この慣行は他のアジャイル慣行を強化するように思われる

ミームプレックスから個々のミームを取り除くと、ミームプレックスの強度が弱まるか、破壊される可能性がある

例 : 集合的なコードの所有権を削除すると、アジャイルの採用が完全に崩壊する可能性がある

競合するミームプレックスは、他の選択肢から注意をそらすため、相互に強化し、必要とする複数の競合するミームプレックスが存在する可能性がある

ミームの起源は異なる場合があり、複数のミームプレックス間で交換および共有することもできる

アジャイルのブランドと方法論をミームプレックスと考えることは有益

その唯一の目的と価値は、個々のアジャイルプラクティスのコピーを促進すること

文化人類学の観点からは、人間がアイデアをグループ化して 1 つの名前でコピーするという概念を発明していなければ、文化、宗教、科学は存在しなかっただろう

問題が時間とともに悪化するという概念

人々が環境を台無しにするすべての小さな問題に取り組み、物事を頻繁に掃除することによって、より深刻な犯罪を防ぐことができると信じられている

多くの学者が割れ窓理論を批判してる : 相関と因果関係の問題

B = f(P, E)

科学的な方程式ではなく、単に経験から導き出されたもの

人々はお互いの規範や行動 (ミーム) もコピーし、悪い行動はより悪い行動 (正のフィードバックループ) につながる可能性が高いので、割れ窓理論は直感的

ここから学べること

大きな問題は、多くの場合、まだ管理可能であるときに芽が摘まれなかった小さな問題として始まる

問題が大きすぎて処理できない場合は、関連しているが小さい別の問題をターゲットにする

まとめ

学習システムは、競合するルールで構成される複雑なシステムとしてモデル化できる

これらのルールは多様である可能性があり、必ずしもチーム全体で同期されているとは限らない

チームでのルールの開発は能力の問題

アジャイルマニフェストは、能力について明示的に言及したことはない

能力の開発は、規律と技能の 2 つの側面

補完性原理は、ルールは最も低い権限のある機関のレベルで作成する必要があることを示唆している

つまり、ルールの作成は (権限のある) チームに委任する必要がある

さらに、ルールを作成せずに破棄する必要がある場合がある

チーム内のルールが多すぎると、誤ったセキュリティの感覚とリスク補償の傾向が生じる

ミーム学と割れ窓理論の研究を参照して、行動が人々のグループ間でどのように伝播するかを学び、組織でのグッドプラクティスの導入に取り組む方法を理解できる

Chapter 11 : How to Develop Competence

組織は生きているシステムなので、組織全体に 1 つの成熟度レベルを割り当てることは役に立たない

成熟度モデルを事業で使用する方法は、組織のプロ意識を扱い、評価するための適切な方法ではないと考える

組織全体を分類するのではなく、特定の人々によって実行された特定の活動のみを分類する必要がある

この章では、複雑さに基づいた成熟度とプロ意識についての筆者の見解を説明

組織の 「成熟度」 は、多くの人が行う多くの活動の成熟度によって生み出される創発的な資質

組織で能力を開発する 7 つのアプローチ

前章で見た交通管理の規律に対する 7 つのアプローチをソフトウェア開発に変換し、規律の概念を能力にまで広げる

最初のアプローチが出発点で、後続の各アプローチは、前のアプローチのフォールバックシナリオ

アプローチ 7 つ

Self : 自己規律 (self-discipline) と自己啓発 (self-development) は、特定の行動パターンを採用するための自分自身のイニシアチブ

例 : 妥当な時間内に他の人の電話やメールに応答する必要があると誰も私に言う必要はない。 それは自分で採用した行動の一部であり、自身で固執するつもり

Coach : コーチングは、特定のスキルや行動を発達させることを目的として人を訓練する方法

例 : コーチは、誰かが適切なメールの使用パターンを確立するのを助け、他の人のメールを放置しないようにすることができる

Test : 権威によって人が必要なスキル、行動、および特定のタスクを実行する意欲を示していることを確認したと示される

Tools : 標識と信号によって人々の行動を誘導するように、人の行動を誘導するツールを利用する (To-do リストなど)

Peers : グループ内の仲間が、グループの規範に準拠するように行動を変えるように促す

例 : 初めて人が私を待たせたとき、私はまだ返事を待っているときに優しくそして理解して彼女に思い出させます。 2 回目は、心からの迷惑を伝えるようにします。 3 回目は彼女の頭をかみました。

Supervisors : 監督とは、組織のマネジメントに代わり、人々が適切に仕事をしていることを確認する行為こと

例 : 一部の組織では、人々が電話や電子メールを適切かつタイムリーに処理しているかどうかを時々確認することをお勧めします。

Managers : 指導と統治はマネージャーの仕事の一部

良い模範を示し、組織の利益に反した行動 (例 : 潜在的な顧客を完全に無視することによって企業の評判を傷つける) についてのルール作りと裁定

組織における能力開発は、7 つのアプローチにまたがる関心事

能力は、そもそも個人的な責任

人々が自分で有能な行動を発達させることができないとき、コーチングが必要

コーチが不在か無能ならば、能力の開発は、テスト、適切に使用されたツール、およびその人の仲間のいくつかの組み合わせによって達成される可能性がある

それらが機能せず、監督者が利用できない (または無能である) 場合、マネジャーは失われたビジネスの責任を負う

Optimize the Whole : Multiple Levels

第 4 章では、システム内の間違ったものを測定 (および報奨) する問題について説明した (厄介な副作用がある)

最適化された全体を得るためには、全体を測定する必要がある

測定 (および制約) するものは、最初から最後まで、上から下まですべてをカバーする必要がある

そうしないと、システム内の測定されていない、制約されていない部分が自己組織化して、次善の結果になる

アジャイル専門家は、個々のチームメンバーではなくチーム全体の出力を最適化するために、チームメンバーが自己組織化する必要があると強く信じている

それには同意

だが、多くのアジリストは、個人ではなくチームのみを測定することを提案している

これには反対

それが正しいとすれば、それはビジネスユニット内のチームに適用され、さらに組織内のビジネスユニットに適用されていく

いずれの場合も、サブシステム (のみ) の測定は、次に高いレベルでの部分最適化につながる

極論すれば、適切な指標は 1 つだけ (組織全体とその環境の継続的な存続と成功) になってしまう

これは、特に有用な指標とは思えない

「全体を最適化する」 とは、すべての指標をより高い組織レベルに移動する必要があることを意味するわけではない

より論理的なアプローチは、メトリックの組み合わせによって、測定とシステム全体の理解にギャップが生じないようにすること

5 番目のアジャイルバリューのように表現すると次のようになる

ローカルメトリックよりもグローバルメトリック

右側のアイテムには価値がありますが、左側のアイテムの方が価値がある

しかし、それは右側の項目が重要でないという意味ではない

Optimize the Whole : Multiple Dimensions

9 章で制約の三角形を四角形に拡張したが、ソフトウェアプロジェクトのダイナミクスを伝達するには不足がある

9 章で見たように、スコープは機能と品質に分けられる

同様に、資源は人とツールに分けられる

プロセスも追加できるし、ビジネス価値も追加できる

これで少なくとも 7 つの軸ができるが、これでも完璧ではない

ここで重要なのは、どこかの軸に焦点を合わせるのではなく、全体を測定すること

機能やプロセスのみを測定すると、モチベーションが低下したりビジネス価値の低下につながりうる

簡単でもよいので 7 つの軸全てを計測すること

table:測定の例

Functionality 完了したストーリーポイント (ベロシティ)

Quality テスターによって報告された問題

Tools 月のコスト

People チームメンバーから報告された障害 (Impediments)

Time live release (とは？) まで残された日数

Process 完了したチェックリスト

Value 時間当たりのユーザーの利用者数の増加など

開発マネジャーが元の 5 つの視点 (財務、顧客、社内ビジネス、イノベーション、学習) を、ソフトウェア開発により役立つはずの上記 7 つの側面に置き換えるとよい

パフォーマンスメトリクスのティップス

パフォーマンスメトリクスは重要

自分がどれだけうまくできているのかを知りたい

マネジャーの責任の一つは、従業員が自分の仕事をどれだけうまくやっているかを知り、理解できるようにすること

いくつかのヒント

スキルと規律の区別 : 人とチームの両方について別々に評価することを推奨

熟練した人々が規律を忘れないようにする

規律のある人々 (手順に従っているから自分はよくできていると思うかもしれない) への自信過剰を避ける

規律を測定する例 : タスクボードは最新であり、会議は時間どおりに開始され、コードカバレッジは常に 95 % を超えている

スキル測定の例 : ビルドの失敗はなく、バグはほとんど報告されておらず、顧客のデモは常に受け入れられている

知識や経験を評価しない : 知識と経験はスキルと規律の前提条件であると考えていますが、人々の知識と経験を測定することはあまり意味がない

知識と経験は存在

スキルと規律は提供すること

複数の活動を評価する : 私たち一人一人には、得意なことと得意でないことがある

スコアが高い別のアクティビティがある場合は、あるアクティビティの悪い評価の屈辱を受け入れることができる

複数の評価があると、人に対して正直で公平になりやすくなる

ソフトウェアリリースの品質とその適時性、顧客満足度と費用対効果、遵守されている公式基準、およびチームの柔軟性について、複数の活動で評価する

複数のパフォーマンスを評価する : 一般に、人々は同様の活動に対して複数回評価されることを好む

どうしてもパフォーマンスが悪い日もある

彼らは次回より良いことをするチャンスを望んでいる

実施するプロジェクトごと、および本番環境に移行する新しいリリースごとに評価

可能な場合は相対的な評価を使用する

チームのパフォーマンスを以前のパフォーマンスと経時的に比較 (「前回よりも 15 ％ 向上している」)

組織内の他のチームに対してや、外部企業に対しても

フィードバックループをできるだけ短くする : アクティビティの時間とメトリックからのフィードバックの間の遅延をできるだけ少なくする

先行指標と遅延指標の両方を使用する

先行指標は、変化したときに、目標を達成するための正しい軌道に乗っている可能性があることを示す指標

例 : 単体テストのコードカバレッジの増加は、製品の品質が高いことを示している可能性がある

遅延指標 : 作業の完了後に目標を達成したかどうかを確認するメトリック

例 : 顧客から報告された欠陥の減少は、製品のリリース後に品質を検証

自分で評価を作成しない : 個人またはチームのパフォーマンスに関するマネジャーとしてのあなたの意見の価値は、非常に非常に小さい

定性的であれ定量的であれ、すべての評価が環境によって生成されていること

検察官ではなく、裁判官になること

自己開発のための 4 成分

規律のための 4 成分と、それらをどう支援するか

重要さの認識。 何かの価値を理解していないと、それを始め、続けるための規律はない

リファクタリングが重要である、というようなことを啓蒙する

基本的な時間管理スキル。 忙しい毎週のスケジュールに重要なことを合わせられなければ、続かない

重要性と緊急性を区別する方法を伝えたり、定期的な活動のために時間枠を予約する方法とスケジュールを作成する方法を示したりする

理解と時間管理に適切に取り組んだあとは、忘れないこと

おそらく最も難しいものは、やる気を起こすこと。 動機なくして規律なし

タスクをより楽しくする方法を人々に示すこと

さらに、あなたが規範を示してリードする

多くの組織では、機能マネジャーが自己開発を支援する責任があるという考え

マネジャーとして、従業員のスキル、知識と経験、訓練、そして規律に関心を持つ

マネジャーの仕事の一部は、直属の部下を指導して、組織内での能力と有効性を高めること

パフォーマンスの問題に取り組むことを決定した人を指導したり、新しいスキルや洞察を開発するために指導したりすることができる

他の選択肢もある

人をマネージすることは人を指導することとは異なる

責任を委任し、シニアの人がジュニアの同僚にスキルと能力を伸ばすように指導する権限を与える

全ての人にとってマネジャーは組織に 1 人しかいないが、コーチは領域に応じて複数人持つこともできる

シニアな人にコーチを依頼もできるし、社外の人に依頼しても良い

マネジャーのコーチングの責任は、マネジメントの文献で頻繁に繰り返されるテーマ

マネージャーが部下よりも高い能力を持っていることを前提とする従来の階層的思考から成長した誤謬

複雑なシステムの観点からは、これはナンセンス

マネジャーとして得意である必要があることは、組織の内外のどの人が組織の人々の開発を支援する優れたコーチであるかを理解すること

標準の定義と人材育成に責任を持つ

コンピテンシーリーダーが何をするか？

何よりもまず、組織内で優れたテクノロジーの開発に取り組む

それらは、実現可能なアーキテクチャ、間違いのないプロセス、進化的開発、および技術的専門知識の観点から、優れたソフトウェア開発を組み立てることから始まる

彼らは基準を設定し、コードの明確さを主張し、コードレビューが学習の強化に焦点を合わせていることを確認する

最も重要な役割は、専門知識を開発するために、実践を導く教師の役割

メンターはコーチではないが、言葉は同義語であるかのように混同されることがよくある

メンターは、従業員の個人的な生活やキャリアを扱い、特定の議題はなく、個人のみに焦点を当てる

コーチは人の仕事と責任を扱い、特定のアジェンダまたは開発アプローチを持ち、人のパフォーマンスに焦点を合わせる

マネジャーとしてコーチを任命することはできるが、メンターについては何もできない

メンターは恋人や愛人のようなもの

誰かにメンターがいるかどうかは非常に興味深いが、それはあなたが関与することではない

インターンシップのメンターみたいなやつも、マネジャーが関与すべきではないって意見なのかな

認定 (証明書) について

多くのアジャイルソフトウェア開発エヴァンジェリストと同様、認定に誇りを持つ人に対して懐疑的

認定だけでは役に立たないが、認定は能力開発を扱ううえでの大きく複雑なアプローチの一部として有効だと考える

認定は、それらの砂漠を肥沃にする方法

個人的なコーチ、社会的圧力、適切なツール、いくつかの監督、および有能なマネジメントと組み合わせることで、認定は 100 倍の価値を持つ

集団のメンバーが何らかの行動を示すと、残りのメンバーは同じ行動を採用する圧を感じる

意識すべきこと

1. 社会的圧力が機能するのは、めんばーがその集団に所属したいと思うときだけ (チームビルディングが必要)

2. チーム全体で共通の目標を持つことで、圧力の方向性を決める

3. 自己組織化に任せる (マネジャーは退く)

適応性のある (adaptable) ツールを使う

人やプロセス同様、ツールは慎重に選ぶ必要がある (ツールに合わせてビジネスを変更するのではない)

監督者 (supervisor) についての検討

組織内の人間は、コンピュータよりもはるかに多くの間違いなどを犯す

対応策として思いつくのは監督者が検査することだが、アジャイルやリーンの実践者は反対しがち

「ゼロ欠陥」 (Zero Defects) のスローガンは逆効果で役に立たない (達成できないしコストがかかりすぎる)

このスローガンでは暗黙的に欠陥をすべて同じ重さで扱っているが、優先度をつけるべき

欠陥によっては、後から検査する方が安価な場合もある

検査 (inspection) の典型的な形式の 1 つは、評価 (assesment)

アジャイルプラクティスを採用した後に開発チームを検査するため、アジャイルプラクティスの採用でミスをする方法ではない

能力は、自己規律、コーチング、認定、社会的圧力、ツール、および監督を通じて達成される

基本的にはこの連鎖の早い段階で問題を解決する方が安価

監督と検査は最終的なゲートであり、検査する必要は少ないほど良い

が、ゼロ検査で問題が起こらないようにすることはコストが高すぎるので、少なからず検査は必要

年次業績評価には問題がある

ただし、多くの 360 度評価は昔ながらの父権的な要素があるのでよくない

より良いやり方 : チームメンバー全員が一堂に会して、一人一人に対して全員からフィードバックする

信頼と敬意と思いやりがあるチームじゃない場合は実施してはならない (そうじゃない場合は先に別の問題を解決する必要がある)

基準を育てる (Grow Standards)

仕事を基準と比較することでパフォーマンス評価をする

自己組織化されたチームでは、自分たちで基準を管理できる (自分たちの成長に合わせて基準自体を高められる)

マネジャーの仕事は、ルールや人ではなくシステムを成長させること

ポジティブフィードバックループを通して能力の基準が発生することを可能にする

強みに集中できるように、苦手な分野があることも許容する

小さな問題も放置しない (大きな問題は小さな問題から始まる)

まとめ

能力開発の 7 つのアプローチ : 自己啓発、コーチング、認定、社会的圧力、適応可能なツール、監督、および管理